Personal or organizational data is often stored at a central location that can be accessed by one or more remote devices. Software applications can be written that run on the remote, or client, devices and send data to, and receive data from, the central location. In many cases, rather than directly retrieving data from a data store, such as a database, a client device sends data requests (e.g., to read or update data) to a data service, which may be located on the same computer system as the data store or on a different computer system. The data service can process data requests from the client device, including translating data to and from a representation used by the client device and a representation used in the data store.
Typically, a data service is set up to process data requests in a specific way. That is, the data service expects clients to request particular data fields having particular data types, or to send updates for particular data fields in particular data types. Such a data service can be advantageous, as it can avoid each client application having to implement functionality provided by the data service. However, client applications are typically limited to using particular data attributes, such as a particular data type for a particular data field, which can limit flexibility in creating client applications.
In some cases, a client application may use multiple data attributes for a particular field by using multiple data services, or multiple data models for a data service. However, the use of multiple models or services can increase the number of requests sent between the client application and the data service, and between the data service and the database, which can consume computing resources and increase response time. Also, data services typically transfer large amounts of metadata to a client application when a connection is established, thus causing applications to be less responsive. Accordingly, room for improvement exists in data services that mediate access to data.